home *** CD-ROM | disk | FTP | other *** search
- Path: engnews1.Eng.Sun.COM!taumet!clamage
- From: clamage@Eng.sun.com (Steve Clamage)
- Newsgroups: comp.std.c++
- Subject: Re: Use of standard exception classes
- Date: 15 Apr 1996 02:47:30 GMT
- Organization: Sun Microsystems Inc., Mountain View, CA
- Approved: clamage@eng.sun.com (comp.std.c++)
- Message-ID: <4kr853$785@engnews1.Eng.Sun.COM>
- References: <9604121530.AA08606@sun132.spd.dsccc.com> <gregorDpsBEt.Dw0@netcom.com>
- NNTP-Posting-Host: taumet.eng.sun.com
- X-Nntp-Posting-Host: taumet.eng.sun.com
- X-Newsreader: NN version 6.5.0 #21 (NOV)
- Content-Length: 2026
- Originator: clamage@taumet
-
- gregor@netcom.com (Greg Colvin) writes:
-
- >>Another developer on our team has asked
- >> How can we be sure that ANSI C++ library callbacks work
- >> correctly in the face of exceptions? What if ANSI C++
- >> library code catches *our* exception?
- >>
-
- >Not to worry.
-
- >>Is this a problem, or are library functions required to reraise any
- >>exceptions thrown by client code?
- >>
-
- >Client exceptions are intended to be pass through library code uncaught, or
- >at least reraised.
-
- I don't find that requirement in the draft. Perhaps I missed it.
-
- In general, it seems to me that if a callback function throws an
- exception that must be diagnosed as due to that callback and not to
- anything else, that exception should not be derived from other
- exceptions. Otherwise ALL exception-handling code must be rather
- elaborate just in case some such callback might be involved (e.g.,
- in a library you use but didn't write).
-
- Every exception handler would have to determine whether the actual
- exception was in fact derived from the exception it thought it
- was handling, and rethrow it instead of handling it. (The current
- function might not call a callback function, but one of the functions
- it does call might have done so.) If you have to write all your code
- like that, why use exception hierarchies at all?
-
- I suspect it is typically the case that the callback can in fact throw
- a derived exception without causing any difficulities. The callback
- is in a sense part of the implementation of the called function,
- and the problem it finds typically can be thought of as coming from
- the called function.
-
- For example, consider a "get_data" function that has takes a callback
- to retrieve bytes from somewhere. If the callback encounters an error,
- it is probably sufficient to throw an exception the get_data function
- might have thrown on its own. The caller of get_data likely doesn't
- care which sub-function found the problem, but only whether the
- call succeeded or what class of error was found.
-
- --
- Steve Clamage, stephen.clamage@eng.sun.com
-
-
- [ comp.std.c++ is moderated. To submit articles: try just posting with ]
- [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
- [ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
- [ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
- [ Comments? mailto:std-c++-request@ncar.ucar.edu ]
-